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MULTIMEDIA CQMNfTTN ICATIONS OVERPOWP.R T TMPg 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims the, benefit of U.S. Provisional Patent AppUcation No. 
60/234,01 6. filed September 20, 2000, which is incoiporated herein by reference. 

FIELD OF THE INVENTION 
The present invention relates generally to data communications, and specificaUy to 
video and voice communications over electric power lines. 

BACKGROUND OF THE INVENTION 
Data communications using residential power lines are known in the art An advantage 
of using the lines is that only peripheral infiastructure needs to be added to the existing power 
lines in order to transmit and receive the data communications. With appropriate modems, 
power lines can be used to cany aU the types of data traffic that are currently carried on local 
area networks (LANs), wide area networks (WANs) and internets, including real-time voice 
and video. Among the disadvantages of using power lines are hi^ attenuation and the hi^ 
level of interference on flie lines, such as voltage spikes and Gaussian noise. These 
characteristics impose limitations on the available bandwidth and reliability of power line 
communications, which should be taken into account in the data services that arc offered over 
power line networks. 

hi packet networks such as the hitemet, the Real-time Transport Protocol (RTP) is 
commonly used to cany real-time multimedia traffic, such as video and voice. This protocol is 
described by Shulzrimie et al., in •'RTP: A Transport Protocol for Real-Time Applications," 
pubhshed by the Network Working Group of the hitemet Engineering Task Force (IETF) L 
Request for Commraits (RFQ 1889 (1996), which is incorporated herein by reference. RFC 
1889 specifies a format for RTP packets that includes a 12-byte RTP header and a 20-byte 
payload, which are carried together as the payload of a User Datagram ProtocoMhtemet 
Protocol (UDP/IP) data packet. The RTP header includes a sequence" nmnber and time stamp, 
which increase by steps from one packet to the next m a RTP stream, along with a fixed 
synchronization source identifier (SSRC) field. Most of the other fields and flags in Ihe RTP 
header change rarely, if at all. in the course of a RTP session. RTP is connectionless, like 
UDP, in the sense that RTP packets are streamed contmuously fiom the source to the 
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d^dmtioB. with no provisiaa fer y«d^ to. the packets have r«ch«i a»ix destination 

intact. , £c ' 4- 

m hi^ overhead of RTP packets is a cause for concern when multimedia traffic is to 

be carried over low-bar^dwidlh networlcs. Hie KTP, UDP and IP headers of a single packet 
5 addupto44bytes(comparedtothe20.bytepayload). The data link header (such as Ethernet) 
and additional signaling used for tel^hony appUcations. can easily add another 40 bytes, 
leaving only 20% of the diannel bandwiddi for the actual data, hi response to flus concern. 
Casner et al. suggest a method for RTP header compression on a link-by-link basis m IFIP 
RFC 2508, entitted "Compressing IP/UDP/RIP Headers for Ix>w.Speed Serial Links" (1999), 
10 which is incorporated herein by reference. This method takes advantage of flie feet that most 
of the fields in the IF. UDP and RTP head^ do not change at all during the RTP session, or 
change by an increment that is generally constant. On this basis, the IP/UDP/RTP header m 
most of the packets is compressed down to two bytes, or four bytes when UDP checksums are 
included. 

SUMMARY OF THE INVENTION 
B is an object of some aspects of the present invention to proAdde methods and 
apparatus for multimedia communications over power line communication (PLC) networks. 

It is a further object of some aspects of the present invention to provide methods and 
apparatus for efficient, reUable Voice over IP (VoIP) communications using PLC networks. 
20 hi preferred embodiments of the present invention, a communications system 

conq>iises a pluraUty of data transceivers coupled to a network of power lines, preferably 
supplying mams voltage. Topically, the transceivers mdude a concentrator, which comiects 
the power line network to a data communication network trunk, and power line modems in 
subscriber premises, which link subscriber equipment in the premises to the concentrator via 
25 the power Unes. The power Ime modems preferably mdude both computer data ports, to 
which a user may comiect a computer for serial or parallel data transfer, and telephone ports, to 
which the user may comiect a conventional telephone handset. The concentrator is comiected 
via the data communication trunk to a telephony server system, which preferably includes a 
gateway to a pubUc switched telephone network (PSTN). Users can thus send and recdve 
30 telephone calls over the power lines by communicatmg through the concentrator with the 
telephony server, using either their telephone handsets or telephony applications on then: 
computers. 
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The transceivers monitor the traffic that they are conveying in order to detect streams 
of voice or video traffic, preferably by detecting RTP packets. When either the concentrator or 
one of the subscriber modems detects such a stream, it signals the transceiver at the other end 
of the link to estabUsh a RTP comiection for carrying the traffic. The connection is assigaed a 
5 short (preferably one byte) connection identifier. The connection context, comprising the 
RTP, UDP and IP parameters that do not vary j&om packet to packet in the stream, is stored at 
both ends of the link, indexed by the connection identifier. Subsequently, for the duration of 
the connection, the sending transceiver removes the IP/UDP/RTP packet headers and, as long 
as the header parameters have not changed, substitutes a brief header containing the 
10 connection idaitifier and a sequence number for detecting lost packets. Periodically, the 
receiving transceiver returns an acknowledgment packet to the sender, indicatmg the sequence 
number of the last packet that was received mtact, and infomiing the sender of any lost or 
comqited packets, hi this way, the narrow bandwidth of the PLC network is used efficiently, 
by reducing substantially the overhead of voice and video streams. At the same time, the 
rehabihty of voice and video communications is enhanced by addmg an acknowledgment 
mechanism tiiat is absent in the connectionless protocols usually used for real-time 
cammunications. 

There is therefore provided, in accordance with a preferred embodiment of the present 
invention, a method for commimication, including: 

estabUshing a data link between first and second transceivers over an electric power 
line; 

receiving a sequence of data packets for transmission over tiie data link, fhe sequence 
belonging to a session of a connectionless real-time network protocol; 

responsive to a first packet in the sequence, estabUshmg a reUable connection channel 
25 for the session over flie data link between the first and second transceivers; and 

transmitting tiie packets in flie sequence fixan the first to the second transceiver over 
the reliable connection chaimel. 

lypically, tire packets include header information, and transmitting the packets 
includes compressing the header infonnation in flie packets transmitted using flie chamiel fiom 
flie first to flie second ti-ansceiver. Preferably, estabUshing flie reUable connection channel 
includes staring context mformation wifli respect to flie session at tiie firet and second 
transceivers, and compressing flie header information mchides compresshig flie header 
information using flie stored context mformatioa Furflier preferably, storing flie context 
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infimnation includes conveying the context infonnation to the second transceiver along vath a 
channd identifier in the fiist padcet in the sequaice, and comi«cssing the header 

includes inserting the channel identifier in the packets in the sequence foUowing the first 
packet as a reference to the context information. Most preferably, the method includes 
5 reconstructing the compressed header infoimation at the second transceiver using the stored 
context information referenced by the channel identifier. Additionally or alternatively, 
compressing the header information includes detecting changes in the header information m 
successive packets in the sequence, and encoding the changes. 

Preferably, the method includes sending an acknowledgment fiom the second 
10 transceiver to the first transceiver responsive to at least some of the packets in the sequence 
transmitted by the first transceiver, thereby maintaining flie reliable connection channel. 
Further preferably, estabUshing the reUable connection channel includes detemiinmg an 
acknowledgment interval that includes a given number of the packets, and sauJing the 
acknowledgment includes sending the acknowledgment every time the given nnmber of 
15 packets has been received at the second transceiver. Most preferably, transmitting the packets 
includes adding an error detection code at the first transceiver to one of the packets in the 
acknowledgment interval, and sending the acknowledgment includes checking the error 
detection code at the second transceiver, and indicating a result of the checking in the positive 
or negative acknowledgment returned by the second transceiver. 
20 Additionally or alternatively, transmitting the packets includes adding a channel 

sequence number to each of fiie packets, and sending the acknowledgment includes sending an 
indication fiom the second transceiver to the first transceiver when the dwnnel sequence 
numbra: of the packets received at the second transceiver deviates firom a consecutive order. 

Further additionally or alternatively. estabUshing tiie reUable connection channel 
25 includes sending a request fiom the first transceiver to the second transceh^er to allocate a 
resource for the channel, and sending the acknowledgment inchides indicating to the first 
transceiver in a negative acknowledgment that the second transceiver does not have the 
resource available to opea the chaimel. 

In a preferred embodiment, the first and second tiansceivers include a subscriber 
30 transceiver in a subscriber premises and a concentrator, and wherein the electric power line is a 
part of a mains voltage power line networic to which the subscriber transceiver and die 
concentrator are connected. Typically, the subscriber transceiver is one of a plurality of such 
transceivers in multiple, respective subscriber premises connected to the power line network. 
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and the concentrator is coupled to link the plnraKty of the transceivers to a packet 
communication trunk. Preferably, receiving the sequence of the data packets includes 
receiving a real-time data flow to be conveyed between the subscriber premises and a network 
server via the packet communication trunk. Most preferably, receiving the real-time data flow 
includes receiving telephorqr data, and the network server includes a telephony gateway, which 
is coupled to a pubUc switched telephone network (PSTO), Jn a fur&er preferred embodiment, 
receiving the telephony data includes receiving data associated with a telephone caU placed 
fiom one of the multiple subscriber premises comiected to the power line network to another 
of the multiple subscriber premises, and the telq)hony gateway is further configured to serve 
as a virtual exchange, so as to convey the telephony data fiom the one of the subscriber 
premises to the other without saiding the data throu^ the PSTN. 

la another preferred embodiment, receiving the sequence of the data packets includes 
receiving real-time multimedia data, preferably video data and/or voice data. Most preferably, 
receiving the voice data includes coupling a telephone handset to one of the transceivers, and 
conveying the voice data as an analog audio signal between the one of the transceivers and the 
telephone handset Alternatively, receiving the voice data includes coupling a personal 
computer to one of the transceivers, and conveying the data packets between the one of the 
transceivers and a voice apphcation on the personal computer. 

Preferably, receiving the sequence of the data packets includes iweiving the packets in 
accordance with a Real-time Transfer Protocol (RTP). 

There is also provided, in accordance with a preferred embodiment of the present 
invention, communication ^aratus. including a first data transceiver, which is configured to 
estabUsh a data link with a second data transceiver over an electric power line, such that upon 
receiving a sequence of data packets for transmission over the data link, the sequence 
belonging to a session of a comiectionless real-time network protocol, the first data transceiver 
is adapted, responsive to a first packet in the sequence, to estabhsh a reKable connection 
channel for the session oyer the data link with the second transceiver and to transmit the 
packets in the sequence to the second transceiver over the reKable comiection channel. 

In a preferred embodimait. flie sequence of the data packets includes real-time 
30 multimedia data, including voice data, and the fir^ transceiver includes a telq,hone adapter, 
which is configured to exchange the voice data in the form of analog audio signals to and from 
a telephone handset. Alternatively or additionaUy. the first transceiver includes a compute 
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canmiunication port, which is configured to exchange the voice data in the form of voice 
padcets to and from a voice appUcation on the personal conq>uter. 

Preferably, the first transceiver includes one of a subscriber transceiver in a subscriber 
premises, and a concentrator, and the electric power line is a part of a mains voltage power line 
5 network to which the subscriber transceiver and the concentrator are connected. 

niere is additionally pri>vided, in accordance with a prefeired embodiment of the 
present invention, communication apparatus, including: 

a subscriber transceiver, for deployment in a subscriber prtanises. the subscriber 
transceiver being adapted to be coupled to an electric power line belonging to a mains voltage 

1 0 power line network; and 

a concentrator, coupled to the power line netwoik so as to convey data between the 
subscriber transceiver and a packet communication trunk, the subscriber transceiver and the 
concentrator being configured to estabUsh a data link therebetween over the electric power 
line, such that upon receiving a sequence of data packets for transmission over the data link, 
15 the sequence belonging to a session of a connectionless real-time networic protocol, the 
siAscriber transceiver and the concentrator are adapted, responsive to a first packet in the 
sequence, to establish a reUable connection channel for the session over the data link and to 
transmit the packets in the sequence from one to another over the reliable connection channel. 
The present invention will be more fiiUy understood from the following detailed 
20 description of the preferred embodiments thereof taken together with the drawings in wHch: 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram that sdiematicaUy illustrates a system fi»r power line 
communications (PLC), in accordance with a pref«redembodimetit of the present invaition; 
Fig. 2 is a block diagram that schematically shows details of a power fine data 
25 transceiver, in accordance with a preferred embodiment of the present inventiom 

Fig. 3 is a block diagram that schematically shows communication protocols used to 
carry voice traffic in a PLC system, in accordance with a preferred embodiment of the present 
invention; 

Fig. 4 is a table that schematically iUustrates a packet header used in real-time network 

30 communications; 

Fig. 5 is a flow chart that schematically illustrates a method for compressing packet 
headers in a PLC system, in accordance with a preferred embodiment of the present invention; 
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Fig. 6 is a flow chart that schematically iUustrates a method for decoiBpressing 
compressed packet headers, in accordance with a preferred embodiment of the present 
invention; 

Figs. 7A-7D are tables that schematically iUustrate packets headers used in the header 
5 conqiression and decompression methods of Figs. 5 and 6; and 

Fig. 8 is a flow chart that schematically ilhistrates details of a method for packet header 
con^sion. in accordance with a preferred embodiment of the present invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
Fig. 1 is a block diagram that schanatically iUustrates a commmucation system 20, in 
10 accordancewithaprefenedembodimentofthepresentinvention. System 20 is built around a 
power line communication (PLQ network 22, which uses a power line 24 to carry digital 
packet communications to and fiom a plurality of subscriber premises 26, 28, .... Power line 
24 preferably comprises a network of power Knes supplying mains voltage, typically at a level 
of 1 20 VAC or 240 VAC, which share a common step-down transformer 30, comiecting power 
15 line 24 to the medium/high-voltage power grid. It wiU be predated, however, that the scope 
of the present iiivention is not limited to a specific level or type of line voltage. 

Premises 26, 28, .... typicaUy comprise homes and/or offices and/or other receiving 
mrits of the electric power. Each premises is served by a transceiver 34, which acts as an 
interfece between power line 24 and subscriber equipment, such as a personal computer 36 and 
a telq,hone 38. Transceiver 34 is described in greater detail below with reference to Fig. 2. 
One or more master transceivers, referred to herein as a concentrator 32, couples power line 24 
toapacketnetwoAtrunk40. The trunk typicaUy has the form of a wide area network (WAN) 
maintained by an electric utility company to carry communications between the concentrators 
on different low-voltage segments of the power system, such as on Ime 24. 

Trunk 40 is typicaUy coupled to a variety of different pubHc communication networics. 
including the Internet and a pubUc switched telephone network (PSTN) 44. This comiection 
enables subscribers in premises 26, 28. to place and receive telephone calls over PLC 
network 22. Preferably, the caUs are carried between transceivers 34 and a telephony gateway 
42 m the fomi of packetized voice and signaling data, tjpically using Internet Protocol (IP) 
commmiications on both power line 24 and trunk 40. Gateway 42 interfaces with PSTN 44 
converting IP packets to PSTN audio and signaling, and vice versa, as is known in the art' 
Signaling for caUs on Pix: networic 22 is routed to a gatekeeper 46, which is a server 
responsible for tasks such as assigning an IP address to the caUing party, veri^ that the 
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caUed party is available and ihat the call is authorized, and monitoring calls for billing 
purposes. A network management system (not shown) coupled to trunk 40 is responsible for 
allocating bandwidth to calls, depending on the load on PLC networic 22. Preferably, the 
level of compression of the audio data carried on network 22 and trunk 40 is variable, under 
control of the network management system, in response to variations in the networic load. 

As an addition or alternative to gateway 42. telephone calls to and from transceivers 34 
may be handled throu^ a virtual private branch exchanjge (PBX) 48, coupled to trunk 40. 
PBX 48 is preferably implemented as a special telephony ^pUcation running on a 
general-purpose networic server. In addition to interfecing with PSTN 44, PBX 48 acts as a 
switch in a private telephone netwodc serving customers of the electrical utiUty company who 
use PLC network 22 for their telephone calls. EBX 48 routes local telephone calls between 
such customers through trunk 40 and the subscribers' local power lines 24, without using 
PSTN 44. This feature of the PBX allows the utility company to offer local telqihone service 
at reduced rates, relative to the PSTN. Outgoing and incoming calls involving td^hone 
subscribers outside the local PLC networic are routed by PBX 48 to and from PSTN 44, in a 
manner similar to VoIP gateway 42. 

Voice telephony is thus carried over PLC network 22 in much the same way as other 
types of packet data, but with a few important differences. One difference is that the telephony 
packets are preferably assigned a high level of priority, relative to other types of traffic, so as 
to provide adequate quaKty of service (QoS) for real-time voice. In addition, the voice packet 
headers are compressed to conserve bandwidth on the PLC network, as described in detail 
hereinbelow. Other real-time multimedia traffic, such as real-time video, which is typically 
fed to PLC network 22 from the Internet and from entertainment networks, is preferably 
treated in a similar fashion to voice, with priority and header compression. Therefore, 
although preferred embodiments are described herdn primarily with reference to telephony 
appUcations, it will be understood that the principles of the present invention are similarly 
explicable to other types of real-time data traffic. 

Fig. 2 is a block diagram that schematically shows details of one of subscriber premises 
transceivers 34, in accordance with a prefferred embodiment of the present invention. The 
design and operation of transcdver 34 are described in greater detdl in PCT Patent 
AppUcationPCT/ILOl/00745. filed August 12. 2001, which is assigned to the assignee of the 
present patent appUcation and whose disclosure is incorporated herein by reference. 
Transceiver 34 comprises a multi-function modem unit 50, which acts as an interfece between 
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power line 24 and low-voltage data infonnation lines. Modules of unit 50 act as 
data-conveision circmtxy, accepting incoming data fiom elements such as a network or a 
telephone and converting the data to signals compatible Mrith the power line, as weU as 
performing the reverse operation. Certain modules also act as a data commumcation controUer 
52, and as level-setting circuitry for transmission of the data. 

Transceiver 34 is preferably coupled to line 24 by an indusHy-standaid power socket 
56. A physical interface (PHY) module 54 acts as a fuU-dupl«c converter between serial data 
signals of a data link unit 58 and power line signals of power line 24. A logic module 60 
commmricates with a central processing mut (CPU) module 62, v*ich is used to operate and 
control other modules con^iised in the transceiver. Ih addition to acting as an overall 
controUer for transceiver 34. CPU 62 is utilized to convert data received by and transmitted to 
other modules of the transceiver, as well as to control routing of communications between 
transceiver 34 and other elements of PLC networic 22. CPU 62 preferably operates using a 
volatae memory 66 such as a random access memory (RAM), containing a routing table 68. 
and a non-volatUe memory 70. such as a flash memory. Memories 66 and 70 are coupled to 
CPU 62 by an internal bus line 64. 

CPU 62 communicates with the other modules of transceiver 32 via logic module 60, 
which acts as a multiplexer, transferring data to and fiom subscriber equipment interfeci 
modules 72, 78, 80, 82 and 86, whose functions are des^bed below: 

• CODEC module 82, preferably an industry-standard CODEQ transmits and 
receives standard telephone signals via an industry-standard connector 84 to and fiom 
telq,hone 38. The CODEC converts the analog telephone signals to a suitable digital 
&mn, such as the H.323 format promulgated by the Ihtemational Telecommunications 
Union (ITU), and vice versa, in a ftdl^uplex manner. 

• ECP module 80 commumcates with personal computer 36 via an industry-standard 
parallel port of the conq>uter. 

• RS-232 module 86 provides industry-standard serial communication, via a 
coimector 128. 

• Ethernet module 72 provides packet data commxmications, using a standard 
protocol such as lOBaseT. via a comiector 74. Computer 36 may comiect to module 
72 either directiy via connector 74 or via a LAN 76. 
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. Altenatively or additionaUy. Universal Serial Bus (USB) module 78, which is 
preferably coupled directly to CPU 62, communicates with a USB host via connector 
74. 

Fig. 3 is a block diagram that schemadcaUy illustrates protocols used in voice 
5 communicatioiis over VUC network 22. in accordance with a preferred embodiment of the 
present invention. The communications are shown, by way of example, as takmg place 
between either personal computer 36 or telephone 38 and VoIP gateway 42. via subscriber 
PLC transc«ver 34 and concentrator 32. The communications are generated at the subscriber 
end as a RTF packet stream, which is preferably produced by a suitable IP telephony 
10 appUcation running on computer 36. Alternatively, the subscriber may use telephone 38 to 
generate audio and signaling. In this case. CODEC module 82 converts the tel^hone output 
to standard digital form, and data link unit 58 generates the RTP header data, as well as 
processing the RTP packets retamed from the party at the other end of the telephone call. 

Thus, a subscriber-end protocol stack 100 shown in Fig. 3 comprises RTP. UDP and IP 
15 layers on the subscriber side, running over local media access control (MAC) and physical 
layer communications provide by the appropriate subscriber equipment mterfeces, such as 
Ethernet mterface module 72. When CPU 62 generates or detects an outgoing RTP/UDP/IP 
packet stream, it preferably estabUshes a point-to-point connection between transceiver 34 and 
concentrator 32 for the purpose of carrying the stream, and then compresses Ihe packet headers 
20 in the RTPAJDP/IP session, as described in detail hereinbelow. Concentrator 32 preferably 
functions in like manner with respect to incoming packet streams from trunk 40. The RTP, 
UDP and IP layers are then carried on power line 24 between subscriber transceiver 34 and 
concentrator 32 by a special, compressed telephony layer, over the PLC MAC and physical 
layers generated by data link unit 58 and PHY module 54. The MAC layer protocol is 
25 described in detail in the above-mentioned PCT patent appHcation. 

In a concentrator stack 102. running on concentrator 32, the compressed telephony 
layer for outgoing calls is decon5)ressed to recovca: the original RTP, UDP and IP headers. 
Conversely, incoming RTP/UDP/IP headers are con5)ressed for transmission to transceiver 34. 
The RTP/UDP/IP voice packets may also be carried over packet trunk 40 in compressed form, 
30 anddecompressedatgateway42oratanotherpointalongtheway. The MAC and PHY layers 
on the trunk side of concentrator 32 are typically those of a standard data link protocol used on 
the packet network to which trunk 40 belongs, preferably an Ethernet protocoL 
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A VoIP gateway stack 104 is used by gateway 42 to interfece with PSTN 44. Hie 
gateway stack is preferably built on protocols known in the VoIP art, inchidii^g H.323, along 
with the Session Initiation Protocol (SIP) for call signaling and the Media Gatew^ (Control 
Protocol (MGCP) for handling audio data flow. 
5 Fig. 4 is a table that schematically illustrates fields in the RTP/UDP/IP/Ethemet header 

structure, which are used in the compression scheme described below. As indicated by a 
legend at the bottom of the figure, the fields are coded to show which typically change in the 
course of a RTP session, and which do not Some of the fields axe shown as being optional or 
"expendable," indicating that fliey can be deleted at one end of the session comiection and 
10 recovered if necessary at the other end. Further information regarding the header fields is 
provided in the above-mentioned RFC 1889 and RFC 2508. 

In a RTP header 1 10. the version and SSRC nmnbers should remain constant for the 
duration of a session. The P. X. CC. M and PT fields in &e header change occasionally at 
most, as does flie contributing source identifier (CSRQ. The packet sequence number and 

15 «°ie stamp fields change fiom one packet to the next. typicaUy by a constant increment The 
expected increment of the packet sequence mmiber is 1, while that of the time stamp dq,ends 
on the CODEC being used. (For example, for 0.729. the t^ical time stamp increment is 160.) 

In a UDP header 112, the UDP source port and destination port do not usually change 
in the course of a session, although they may occasionally do so. By comrention. 
10 even-numbered UDP ports are used for RTP traffic. The UDP segment length is generally 
redundant, since it can be recovered firom packet parameters of lower-layer protocols 
Although UDP packets conventionaUy carry a checksum, this field can also be omitted in some 
or all of the packets. 

In an IP header 1 1 4. most of the fields also change rarely if at all in the course of a RTP 
5 session. As in the case of the UDP length, the IP total length can be deleted and recovered 
subsequently from lower-layer protocol information. TTie IP padcet identification (ID) is 
nonnaUy mcremented by one for each new packet. 

FinaUy. in aa Ethernet header 1 16. the source and destination mfoimation. identifying 
the transceivers at the ends of the link, must remain constant during any given session. 

Based on the information in Fig. 4, it is evident that any given RTP session between a 
subscriber premises transceiver 34 and concentrator 32 can be represented by context 
^formation that changes little if at aU in the course .of a session. As sessions are created, each 
session is assigned a unique context ID (CED). or chamiel number. The session context is 
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Stored in a pool in memory by both the transceiver and the concentrator (for example, in 
memory 66, Fig. 2). The context entries are preferably stored in the memory as a linked list, 
referenced by a hashing function based on a certain number of the least significant bits (LSB) 
of the RTP SSRC and the IP destination address for the respective sessions. Table I below 
shows a preferred structure for the memory pool context entries. 

TABLE I- SESSION CONTEXT PARAMETERS 



Cat^ory 


Field 


Size 
(bits) 


CID 


Context ID (channel number) 


8 


Coiinters 


Number of CONTEXT.STATE (ACK or NACK) 
packets received (see description below) 


8 




Total RTP packets recdved 


16 




Sequential number of con^iressed packet 


4 


State 


Channel state (active, inactive, pending - see below) 


4 




Last xtpdate to this channel - channel is cleared after 
timeout occurs with no update 


32 


ixl Jr 


Pbit 


1 




Xbit 


1 




CC 


4 




Mbit 


1 




Payload type 


7 




Previous sequence niunber 


16 




Previous timestamp 


32 




SSRC 


32 




CSRC (pointer to list) 


16 


UDP 


Source port 


16 




Destination port 


16 


IP 


IHL 


4 




Type of service 


8 




Previous ID 


16 




Flags 


3 
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Fragments 


13 




Time to live 


8 




Source address 


32 




Destination address 


32 




Options + padding 


32 


i^tueraet 


Source MAC address ~ 


48 




Destination MAC address 


48 


ACKs 


Last seg number acknowledged 


4 




Last CRC sent (on seq number) 


16 


D 


Debug state 


1 


Next_entiy 


link to next entry or end of list 


15 



20 



Fig. 5 is a flow chart that schematically illustrates a method for processing an outgoing 
packet stream at transceiver 34, for the purpose of RTP header con,«ession. in accordance 
with a preferred embodiment of the present invention. For the sake of clarity, the process is 
descnbed fiom the per^tive of the subscriber-side transceiver. It will be understood 
however, that a similar process is typically appHed to incoming packet streams by concentrator 
32. Each packet coming into transceiver 34 from the subscriber equipment is processed by 
datalinkumt58,atapacketpreparationstq,120. The data link unit examines each packet at 
a packet examination step 122, to detennine whefter it is a RTP/UDP/IP packet, maldng it a 

candidate forRTPheadercon^ression. Non-RTP packets are sent to concentrator 32 without 
header compression, at a packet sending step 124. 

When unit 58 detennines that it has receii^ a candidate packet for header 
compression, it checks the RIP SSRC and IP destination fields in the packet header against its 
memory pool (using the above-mentioned hashing function) to determine whether the packet 
belongs to a session, or chamiel. ftat has already been opened, at a context checking st«, 126 
If such a session is not found, unit 58 next checks to determine whether it has sufficient 
memory resources available to open a new session, at a channel availabiUty step 128. If there 
IS no chamiel available, the packet is sent without compi^sion. at step 124. Similarly, unit 58 
should also check whether the RTP version is the corr^t one. and whether the RIP payioad 
type is known. If the P bit is set in the RIP header, flie last octet of the packet must contain a 
vahd octet count (less than the total packet length minus the header size). If any of these 
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conditions are not satisfied, a channel should not be opened, and the packet should instead be 
sent without compression at step 124. 

When a new channel is available, data link unit 58 creates the channel in its memory 
pool, and assigns it a context ID (CID), at a channel creation step 130. The memory pool now 
includes the full packet context, as specified in Table I above. To notify concentrator 32 that a 
new channel has been opened, unit 58 replaces the UDP length field m the UDP header (Fig. 
4) with a FULLHEADER identifier field, at a header replacement step 132. The 
FULLJffiADER identifier, shown below in Fig. 7A, includes the assigned CID and the 
starting link sequence number (Seq). The modified packet is tiien sent on to concentrator 32, 
at a new packet transmission step 134. Upon reading the packet header with tiie 
FULLJffiADER identifier, the concentrator opens flie channel in its own memory pool, using 
the CID, Seq and context information in the padcet header, and is now ready to receive 
compressed packets. 

When at step 126. data link unit 58 determines tiiat the current RTF packet belongs to 
an existing session aheady opened in tiie memory pool, it updates the corresponding channel 
time_tag field, at a timw update step 136. It tiien checks tiie channel state (see Table D to 
determine whettier or not tiie channel is active, at an activity checking step 138. A chaimel is 
deemed inactive when tiie concentrator has signaled, using tiie acknowledgment mech^sm 
described below, fliat it has received packets witii errors or tiiat packets have been lost on tiiis 
channel, m such as case, tiie original packet is sent wifliout header compression to 
concentrator 124. A channel may be deemed pending i^ upon an attempt by data link unit 58 
to create the channel, concentiator 32 responds that its memory pool is fiill. Packets are 
likewise sent over pending channels without header compression. Such channels are 
ultimately erased fcom tiie memory pool of data link unit 58 by an aging mechanism if 
resources are not fi:eed so tiiat the pending channels can become active. 

When tiie RTF packet is found at step 138 to belong to an active channel, data Unk unit 
58 performs vaUdity checks to ascertain tiiat tiie channel is still vaUd, at a validity checking 
step 140. The packet header is tiien compressed, and the compressed packet is sent to 
concentrator 32. at a compressed transmission step 142. Details of steps 140 and 142 are 
described below with reference to Fig. 8. 

Fig. 6 is a flow chart tiiat schematically illustrates processing of compressed packets 
received by concentator 32 &om transceiver 34, in accordance witii a preferred embodiment 
of the present invention. (As in tiie case of tiie metiiod of Fig. 5. fliis same mefliod is carried 
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out by data liBk mat 58 of transceiver 34 when it receives packets from the concentrator) 
Upon arrival of each packet from transceiver 34. at a packet arrival step 150. concentrator 32 
checks the packet header. By examining the packet header fields, the concentrator is able to 
determine whether the packet belongs to a known RTP header compression type at a 
suppression determination step 152. If not. the concentrator singly sends the packet on to IP 
trunk 40 without changes, at a packet pass-on step 154. except for the necessary changes to 
Ethernet header 1 16 (Fig. 4) that are mandated by standard protocols. 

When concentrator 32 detects a RTP packet with a suppressed header type, it next 
checks the context ID (CID) in the packet header to determine Aether this chamrel already 
exists in its memory pool, at a channel checking step 156. Tt. memory pool of the 
concentrator (at the receiving end of the RTP session) is nearly the same as that shown above 
for the sending end in Table L One difference is that the memory pool at the receiving end 
containsfte MAC address ofthepacketsource(transceiver34)onPlx:network22^ Another 
IS that the "counters" category contains counts of the number of acknowledgment packets sent 
and the number of RTP packets received on the chamiel. Furthermore, channels at the 
leceivmg end of the connection can have only two states: active and inactive. 

If the CID of the packet does not exist in the memory pool at concentrator 32. the 
concentrator checks the packet to verify that it is a FULL_HEADER type, at a header checking 
step 158. As noted above, this is the packet type that transceiver 34 sends to initiate openmg 
ofanewchamieL If is not the expected FULL.HEADBR tjpe of packet, concentrator 32 
sends a 00m^T_STAl^ packet back to transceiver 34. indicating that it was unable to 
forward the packet, at a context reply step 162. (The CONTBXT_STATB format, shown in 
Fr^ 7D. is used by the rtK>ipient of con^ressed packets to signal acknowledgment -ACK- or 
negative acknowledgment-NACK-ofthepackets. as described below.) Uris situation may 
anse, for example, when the transceiver reboots itself in the middle of the transmission 

sequence, or when the first FUIX_HEADER packet is lost m transit to the co^^ 

-ch cases, the transceiver and concentratormustresynchronizebefore they can^^ 
communications. 

d^tonine «*ed»r H ha. . ,w avrtlabic in to „«„„^po„t a, a. empty 

Cham..! checking Stop ,60. Iftoom«.yofU»tan««ive«i„subaoriberpre=u»«26 28 
are busy n^ldng telephone calls Pu; ne,«* 22, a. concent^tor May .en^r^y' Z 
out of channels. In «ds case, to,, tt, c«>c«totor «^ a CONTEXr.STAra packet back to 
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transceiver 34, indicating that it is out of ftee channels, at a reply step 162. Despite the 
negative response, however, the concentrator is still able to reconstruct the original, standard 
RTP/UDP/IP header by recalculating the UDP length, at a length recalculation step 164, and 
tdnsertmg the length into the UDP header of the packet in place of the FULL.HEADER field 
5 that was substituted by transceiver 34. Hie concentrator then sends the reconstructed packet 

out over IP trunk 40. 

Returning to step 156, if concentrator 32 finds that the CID in the packet header exists 
in its own memory pool, it iq>dates flie timejtag in fiie corresponding channel context, at a 
timer updating step 170. It checks the source MAC address of the packet against the context, 

0 toensurethatflxepacfcetisvaUd,atavaliditycheckingst^l72. It also checks the sequence 
number (Seq) of the packet to ensure that it is exactly one greater than the preceding packet 
received on this channeL If so. concentrator 32 can proceed to decompress the packet and 
reconstruct the RTP/UDP/IP header, at a decompression step 174. Details of the 
decompression process are described hereinbdow. If a packet is missed, the channel becomes 

1 5 inactive, and the packet cannot be decompressed or sent 

In order to maintain synchronization between the sender and receiver of compressed 
packets, the receiver is required to acknowledge the compressed packets it has received, at an 
ACK requirement step 1 76. For this purpose, a tune wmdow, T. is defined at both the sending 
and receiving ends, such that every T compressed packets an acknowledgment protocol is 

20 carried out The sender preferably saves the sequence number and ^ends a cyoUc 
redundancy code (CRC) value to the packet whose acknowledgment is required. The receiver 
recomputes the CRC and compares it to the appended value. If the CRC values mateh, the 
receiver returns an ACK packet (i.e.. a CONTEXT.STATE packet) with the sequence number 
to the sender, at an acknowledgment step 178. If there is a mismatch of the CRC values, the 

25 receiver returns a CONTEXT.STATE NACK packet In an optional debugging mode, the 
receiver may check the CRC of every packet, and send a NACK response to flie sender for any 
packet in vAdch the CRC check foils. When the sender receives the ACK response from the 
receiver, it checks the sequence number and CRC value against the values it has saved, and 
clears the values if they mateh. If the sender does not receive the proper ACK, it sends a 

30 PXJLL_HBADER packet in order to refi«sh the channel context 

When concentrator 32 determines at step 172 that a packet has been lost it must send a 
NACK to transceiver 34, inihe form of a CONreXT_STATE packet The NACK packet 
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reports the sequence number of the last packet received and requests transmission of a 
FULL_HEADER packet to update the chamiel context. 

Figs. 7A.7D are tables Hiat schematically illustrates the types of packets sent between 
transceiver 34 and concentrator 32 in canying out the compression and decompression 
protocols of Figs. 5 and 6. The packet types generally follow the definitions in the 
abov^mentioned RFC 2508. with changes ^piopiiate to the specific constraints and 
requirements of PLC network 22. Fig. 7A shows a FULL_HBADER field 200 that is inserted 
in place of the length field in the UDP header (Fig. 4) of a fuU RTP/ODP/IP packet header. 
Field 200 includes a version number 202 (for example. "01"). context ID (OD) 204. and a 
current sequence number (Seq) 206. An optional «D'» bit invokes the above-mentioned debug 
mode, in ^ch a CRC is added by tbe sender to each of the conq)ressed packets and is 
checked by the receiver. 

Fig. 7B shows a COMPRESSEp_UDP packet 210. which is sent by the transmitter 
^ the P. X or PT field in the RTP header has changed. When such a change occurs, 
additional information must be conveyed to the receiver in order to update the channel context] 
and this information is conveyed by the COMPRESSED_UDP packet. The packet header 
includes OD 204 and Seq 206. as weU as an 'T' flag 212. This flag is set if the IP version 4 
(IPv4) ID has changed by an amount other than one from the preceding packet to this one. If 
'T' is set. packet 210 includes a AIP field 214 that gives the actual ID change. Preferably, the 
change in ID is encoded using a HufBnan encoding scheme, as is known in the art, so that 
common values of the ID change (typically in the range 0:127) ai« encoded as a single byte, 
while less common values take two or ftree bytes. A scheme of this sort is suggested in RFC 
2508. No further encoding of the IP or UDP header is required. (If it were, a 
FULL_HEADER packet would be sent.) The packet next includes UDP data 216, wMch 
comprises the fuU RTP header and payload. foUowed by an optional checksum 218. 

Fig. 7C shows a COMPRESSED_RTP packet 220. which is sent when the changes m 
the RTP/UDP/IP header are minimal. FoUowing OD 204. the packet inchides compression 
flags 222. with the following meanings: 

• "M» indicates that the "M» bit in the RTP header has changed. 

• "S» mdicates that the RTP sequence number has changed by an amount different 
fix)m the usual sequence mcrement. In this case, a ARTP sequence field 224 contains 
the actual change m the sequence number, preferably using a Huffinan encoding 
scheme as described above. 

17 



VP 02/25822 



-( 



i. 



Page 20 of 37 



wo 02/25822 PCT/IIXIl/00872 

• "T' indicates the RTP timestan^ has changed by an amount different from the 
usual time increment In this case, a ARTP timestamp field 226 contains the actual 
change in the timestamp, preferably using a Huffinan encoding scheme as described 
above. 

5 • 'T' indicates that the IPv4 ID has changed by an amount different fix>m one, with its 

actual change given by field 214. 

• When all of M, S, T and I are set, and a CC field 223 is not equal to zero, a CSRC 
Hst 228 is included in packet 220, with a length given by the value of CC. In this case, 
the values MHS^TM-l are artificial, to signal that the packet includes the CSRC list, 

10 and the roles of flags M, S. T and I are respectively assumed by flags M*. S*, T' and I'. 

If the "X" bit is set in the RTP header, the header extension is contained in a RTP header 
extension field 230. The remainder of the packet contams RTP data 232, followed by optional 
padding 234 (if the **P" bit is set) and checksum 218. 

Fig. 7D shows a C01SITEXT_STATB packet 240, used for the ACK and NACK 

15 fimctions described above. An "F" bit 242 is set by the receiver to indicate that its memory 
pool is full, so that a new channel that the transmitter has asked to open must remain in the 
pending state. An "A" bit 244 is set to indicate a positive acknowledgment (ACK), and is 
reset for NACK. Seq field 206 mdicates the sequence number of the last packet that the 
receiver was able to read on this channel. The use of the CONrEXT_STATE packet in this 

20 manner (which differs from that proposed in RFC 2508), with a predefined window for 
positive ACK response by the receiver, turns the unidirectional, connectionless RTP/UDP 
packet stream into a ftill-duplex, connection-oriented protocol within PLC network 22, while 
at the same time saving substantial bandwidth. Both of these features are particularly 
important v/hm working over power line 24, with its high noise level and low bandwidth. 

25 Fig 8 is a flow diart that schematicaUy illustrates the use of packet formats 200, 210 

and 220 in sending compressed RTP packets over PLC network 22, m accordance with a 
preferred embodiment of the present invention. The st^s of the method shown in Fig. 8 
correspond rou^y to vaHdity checldng step 140 and compressed transmission stqp 142 m Fig. 
5, after transceiver 34 has ascertained that the RTP packet in question belongs to an active 

30 channel in its memory pool. 

The method of Fig. 8 is mitiated when transceiver 32 receives a RTP packet to 
compress on a vaHd, active channel, at a packet reception step 250. The transceiver first 
checks fields that are supposed to remain ccmstant over an aotire RTP session: tiie IP source 
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address and the UDP ports, at a constant field checking step 252. If any of these paiameteis 
have changed in the cunent packet, relative to the channel context in the menK>ry pool, the 

current channel is erased, at an erasure step 254. A new channel nmy be created in its place 

with the new parameters. 

5 Next, the transceivo: checks wheflier any of the other IP parameters have changed, at 

an IP checking stq, 256. Hiese fields are also generally constant during a session, with the 
excq,tion of the IP ID field, which is incremented flom packet to packet If any of the 
parameters have changed, other tlian the IP ID mciement. the transceiver sends a 
FULL.HEADERpacket, at a full transmission step 258. This packet refreshes the contmts of 
10 the channel context, but without creating a new channel. 

If the packet passes step 256 successfully, the transceiver checks to determine whether 
any of the P, X or PT fields of the RTP header have changed relative to the channel context, at 
a RTP parameters checking step 260. As noted above, if any of these fields have changed, 
compressed UDP packet 220 is sent, at a conq,iessed UDP sending step 262. If the n» ID 
increment has changed, thepacket wiU also include the appropriate AIPv4 ID field 214. 

If none of these RTP fields have changed, the transceiver checks the other RTP header 
fields, as weU as the IP ID field, in order to encode any changes in the fields, at an RTP 
encoding step 264. These changes include changes in the fields themselves, for the M and 
CSRC fields, as weU as changes in the increment of the sequence number, timestamp and IP 
ID fields. Any changes are encoded in the mamier described above, and the corresponding 
flags 222 and CC field 223 are set accordingly, at a flag raising step 266. Most of the time 
fields 214. 224, 226 and 228 ar« empty, so that flags 222 and field 223 are zero. The packet' 
can now be sent to the concentrator 32. 

In order to monitor decompression processing activities, concentrator 32 preferably 
25 maintains the following counters: 

• Global counters - 

• Total RTP packets reconstructed. 

• Total synchronizmg(FULL_HEADER) packets received. 

• Total semi-con^pressed packets received (COMPRESSED_UDP). 

• Total fiilly-compressed packets received (COMPRESSED_RTP). 

• Total synchronizing packets sent (CONTEXT_STATE with F bit off). 

• Total reject packets sent (CONTEXT^STATE with F bit on). 

• Total active channels. 
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• Total inactive channels. 

• Number of available channels. 
• Per-channel counters— 

• Total conq)iessed packets received. 

5 • Total synchronizing packets sent (CONIEXT.STATE with F bit ofi). 

Reconstruction of the compressed packets, at decompression step 174 (Fig. 6) is a 
minor image process to that shown in Fig. 8. When the compressed packet is a 
COMPRESSED_UDP packet, concentrator 32 generates the decompressed RTF packet to 
send over trunk 40 usmg the RTF channd information in UDP data 216, along with the 

10 remaining context data for the channel that is stored in the memory pooL The concentrator 
increments the IP ID by 1 if 1=0, or by the number indicated in field 214 of the packet if 1=1. 

For a COMPRESSED_RTP packet, if M=S=1^I=1, and CC is non-zero, flie CC field 
in flie channel context is updated with flie value in field 223 of packet 220, and the CSRC list 
in the context is replaced with the contents of field 228 in the packet. This new information is 

15 used in all reconstructed packets, beginning with the current one. Depending on the values of 
M. S, T and I (or of M% S', T' and T. if M=S=T=I=1), Ihe remaining variable fields of the 
RTF packet are reconstructed, using constant increments or the special increments given in 
fields 214, 224 and 226. Header extension 230 and padding 234 are optionally added to the 
packet, the UDP length is recalculated, and the packet is sent out on trunk 40 as a standard 

20 RTP/UDP/IP packet 

As noted above, althou^ the processes of channel creation and of compression and 
decompression of RTP packets are described with respect to packets transmitted from 
subscriber equipment, via transcaver 34, to concentrator 32 over power line 24, similar 
meihods are used to create channels and to compress and decompress packets received by 

25 concentrator 32 from packet trunk 40 for transmission over the power line to transceiver 34. 
Furfliermore, although for the sake of clarity, these processes are illustrated with reference to a 
single connection in the very sinq)le PLC network 22 shown in Fig. 1, it will be understood 
that the methods exemplified by the preferred embodiments described herein may equally be 
appUed m more conq)lex PLC networic topologies, with multiple RTP sessions going on 

30 simultaneously. 

More generally speaking, while RTP/UDP/IP provides particularly fertUe ground for 
creating connection-oriented sessions and performing header compression in a PLC networic, 
the principles of the present invention may also be applied to other connectionless protocols, 

20 
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particularly real-time protocols, that are used in the PLC network environment Furthennoie, 
although preferred embodiments are described hCTsin with specific refwence to PLC netwoilCB, 
the principles of the present invention may also be appUed, mutatis mtOandis, to encapsulation 
and compression of packets transmitted over wireline and wireless networks of other types, 
particularly networics that, like PLC netwoiks; have higji noise and error rates. 

It will thus be appreciated that the preferred embodiments described above are cited by 
way of exanq)le, and that the present invention is not limited to what has been particularly 
shown and described hereinabove. Rather, the scope of the present invention includes both 
combinations and subcombinations of the various features described hereinabove, as well as 
variations and modifications thereof which would occur to persons skiUed in the art upon 
reading the foregoing description and which are not disclosed in the prior art 
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CLAIMS 

1. A meftod for conmnniicationi, comprising: 

estebUshing a data link between first and second transceivers over an electric power 

line; 

5 receiving a sequence of data packets for transmission over the data link, the sequence 

belonging to a session of a connectionless real-time networic protocol; 

responsive to a first packet in the sequence, estabUshing a reUable connection channel 
fiM- the session over the data link between the first and second transceivers; and 

transmitting the packets in the sequence fix>m the first to the second transceiver over 
10 ihe reliable connection channel. 

2. A method according to claim 1. wherein the packets comprise header information, and 
wherein transmittmg the packets comprises compressing the header information in the packets 
transmitted using the channel firam the first to the second transceiver. 

3. A method according to claim 2, v^erein establishing the reliable connection channel 
15 comprises storing context infonnation with respect to the session at the first and second 

transceivers, and wherein compressing the header information comprises compressing the 
header information using the stored context information. 

4. A method according to claim 3, wherein storing the context information comprises 
conveying the context information to the second transceiver along with a channel identifier in 

20 the first packet in the sequence, and wherein compressing the header information comprises 
inserting the channel identifier in the packets in the sequence following the first packet as a 
refopaoLce to the context information. 

5. A method according to claim 4, and con^rising reconistructing the conq>ressed header 
information at the second transceiver using the stored context information referenced by the 

25 channel identifier. 

6. A method according to claim 2, wherein compressing the header information comprises 
detecting changes in the header information in successive packets in the sequence, and 
encoding the changes. 

7. A method according to claim 1, and comprising sending an acknowledgment &om the 
30 second transceiver to the first transceiver responsive to at least some of the packets m the 
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sequence transmitted by the first transceiver, thereby maintaining the leUable connection 
channel 

8. A meihod according to claim 7, wherein estabKshing the reliable comiection channel 
comprises determining an acknowledgment interval that comprises a giv«i number of the 

5 packets, and wherein sending the acknowledgment conqjiises sending lie acknowledgment 
every time the given number of packets has been received at flie second transceiver. 

9. A method according to claim 8. wherein transmitting the packets comprises adding an 
error detection code at Ihe first transceiver to one of the packets in the acknowledgment 
mterval, and wherein sending the acknowledgment comprises checking the error detection 

10 code at the second transceiver, and indicating a result of the checking in the acfcaowledgment 

10. A method according to claim 7, wherein transmitting the packets comprises adding a 
chamiel sequence number to each of the packets, and wherein sending the acknowledgment 
comprises sending an indication fiom the second transceiver to the first transceiver when the 
chamiel sequence number of the packets received at the second transceiver deviates fiom a 

1 5 consecutive order. 

11. A method according to claim 7, wherein estabKshing the rehable connection chamiel 
comprises sending a request fiom the first transceiver to the second transceiver to allocate a 
resource for the channel, and wherein sending the acknowledgment comprises indicating to the 
first transceiver whether or not the second transceiver has the resource available to open the 

20 channel 

12. A method according to any of clahns 1-11, wherein the first and second transceivers 
comprise a subscriber transceiver ux a subscriber premises and a concentrator, and wherein the 
electric power line is a part of a mains voltage power line networic to which the subscriber 
transceiver and the concentrator are connected 

5 13. A method according to claim 12. wherein the subscriber transceiver is one of aplurality 
of such transceivers in multiple, respective subscriber premises comiected to the power Ime 
network, and wherein the concentrator is coupled to link the pluraKty of the transceivers to a 
packet communication trunk. 

14. A method accordmg to clahn 13. wherein receiving the sequence of the data packets 
comprises receiving a real-time data flow to be conveyed between the subscriber premises and 
a networic server via the packet communication trunk. 
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15. A method according to claim 14, wherein receiving the real-time data flow comprises 
receiving telephony data, and wherein the network server comprises a telephony gateway, 
which is coupled to a public switched telephone network (PSTN). 

16. A mefliod according to claim 15, wherein receiving the telephony data comprises 
5 receiving data associated wifli a telephone call placed fixm one of the multiple subsciiber 

premises connected to the power line netwoik to another of the multiple subscriber premises, 
and wherein the telephony gateway is fiirther configured to serve as a virtual exchangp, so as to 
convey the telephony data ftom the one of the subscriber premises to &e other without sendmg 
the data through the PSTN. 
10 17. A method according to any of claims 1-1 1, wherein receiving the sequence of the data 
packets comprises receiving real-time multimedia data. 

18. A method according to claim 17, wherein receiving the multimedia data comprises 
receiving video data. 

19. A method according to claim 17, wherein receivmg the multimedia data conq>rises 
15 receiving voice data. 

20. A method according to claim 19, wherein receiving the voice data conqnises couphng 
a telephone handset to one of the transceivers, and conveying the voice data as an analog audio 
signal betweai the one of the transceivers and the telephone handset. 

21 . A method accordmg to claim 19, wherein receiving the voice data con^irises coi^ling 
20 a personal computer to one of the transceivers, and conveying the data packets between the one 

of the transceivers and a voice application on the personal computer. 

22. A method according to any of claims 1-11, wherein receiving the sequence of the data 
packets comprises receiving the packets in accordance with a Real-time Transfer Protocol 
(RTP). 

25 23. Communication apparatus, comprising a first data transceiver, which is configured to 
establish a data link with a second data transceiver over an electric power line, such tiiat upon 
receiving a sequence of data packets for transmission over the data linli; the sequence 
belonging to a session of a connectionless real-time netwoik protocol, the first data transceiver 
is ad^ted, responsive to a first packet in the sequence, to establish a reliable connection 

30 channel for the session over the data link with the second transceiver and to transmit the 

packets in the sequence to the second transceiver over the reliable connection chaimel. 

24 
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24. Apparatus according to claim 23. wherein the packets comprise header infbnnation. 
and wherein the first data transceiver is adapted to compress the header information in the 
packets fox transmission using the channel. 

25. Apparatus according to claim 24, wherein to establish Ihe leKable comiection channel 
conteirt mfonnation with respect to the session is stored at the first and second transceivers, 
and wherdn the first data transceiver is adq>ted to conopress the header information using the 
stored context information. 

26. Apparatus according to claim 25, wherein the first transceiver is adapted to convey the 
context information to the second transceiver along with a channel identifier in the first packet 
in the sequence, and to insert the channel identifier in the packets in the sequence foUowing 
the first packet as a reference to the context information. 

27. Apparatus according to claim 26, wherein the conq)ressed header information is 
reconstructed at the second transceiver using Ihe stored context information referenced by the 
channel identifier. 

15 28. Apparatus according to claim 24. wherein the first transceiver is ad^ted to compress 
the header information by detecting changes in the header mfonnation in successive packets m 
the sequence, and encoding the chants. 

29. Apparatus according to claim 23, wherein the first transceiver is adapted, after 
establishing the reUable connection channel, to receive an acknowledgment ftom the second 

20 transceiver responsive to at least some of the packets in the sequence transmitted by the first 
transceiver, thereby maintaining the reliable connection channel. 

30. y^paratus according to claim 29, wherein the first transceiver is adapted to instruct the 
second transceiver to send the acknowledgment every tune a given number of packets making 
up a predetermined acknowledgment interval has been received at the second transceiver. 

25 31. Apparatus according to claim 30, wherein the first transceiver is adapted to add an 
error detection code to one of the packets m the acknowledgment interval, and to receive fiom 
the second transceiver in the acknowledgment a result of checking the error detection code. 
32. Apparatus according to claim 29. wherein the fii^ transceiver is ad^ted to add a 
channel sequence number to each of the packets, and to receive an mdication in the 
acknowledgment fi-om the second transceiver when the channel sequence number of the 
packets received at the second transceiver deviates from a consecutive order. 

25 
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33. Apparatus according to claim 29, wherein the first transceiver is adapted to send a 
request to flie second transceiver to aUocate a resonice for flie reUable connection channel, and 
to receive the acknowledgment indicating whether or not the second transceiver has the 
resource available to open the channel. 

34. Apparatus according to any of claims 23-33 wherein the sequence of the data packets 
comprises real-time multimedia data. 

35. Apparatus according to claim 34, wherein the multimedia data con5)rise video data. 

36. >^paratu8 according to claim 34, wherein the multimedia data conipiise voice data. 

37. ^aratus accordmg to claim 36, wherein the first transceiver comprises a telephone 
ad^ter, which is configured to exchange the voice data in the fonn of analog audio signals to 
and 6:om a telephone handset. 

38. Apparatus according to claim 36, wherein the first transceiver con5)rises a computer 
communication port, which is configured to exchange the voice data in the form of voice 
packets to and &om a voice application on the personal computer. 

39. Apparatus according to any of claims 23-33, wherein the comiectionless real-time 
protocol comprises a Real-time Transfer Protocol (RTP). 

40. Apparatus according to any of claims 23-33, wherein the first transceiver comprises 
one of a subscriber transceiver in a subscriber premises, and a concentrator, and wherein the 
electric power line is a part of a mains voltage power line network to which the subscriber 
transceiver and the concentrator are connected. 

41. Communication apparatus, comprising: 

a subscriber transceiver, for deployment in a subscriber premises, the subscriber 
transceiver being adapted to be coiq)led to an electric power line belonging to a mains voltage 
power line network; and 

a concentrator, coupled to the power line network so as to convey data between the 
subscriber transceiver and a packet conmnmication trunk, the subscriber transceiver and the 
concentrator being configured to estabUsh a data link therebetween over the electric power 
line, such that upon receiving a sequence of data packets for transmission over the data link, 
the sequence belon^g to a session of a connectionless real-time network protocol, the 
subsariber transceiver and the concentrator are ad^ted, responsive to a first packet in the 
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sequence, to establish a reKable connection channel for the session over the data link and to 
transmit the packets in the sequence from one to another over the reliable connection channel. 

42. Apparatus according to claim 41, wherein the sequence of the data packets comprises a 
real-tune data flow to be conveyed between the subscriber premises and a network server via 
the packet communication trunk. 

43. Apparatus according to claim 42, wherein the real-time data flow comprises telephony 
data, and wherein the network server comprises a telephony gateway, which is coupled to a 
public switched telephone netwcuk (PSTN). 

44. Apparatus according to any of claims 41-43, wherein the subscriber transceiver is one 
of a plurality of such transceivers in multiple, respective subscriber premises connected to the 
power line network, and wherein the concentrator is coupled to link all of the pluraKty of the 
transceivers to the packet commimication trunk. 

45. Apparatus according to claim 44. wbcrdn the sequence of the data packets conq>rises 
telq>hoirjr data associated with a telephone caU placed from one of the multiple subscriber 
prtanises connected to the power line network to another of tbe multiple subscriber premises, 
and con5>rising a telephony gateway, coupled to the packet communication trunk, which is' 
configured to serve as a virtual exchange, so as to convey the telephony data from the one of 
the subscriber premises to the other without sending the data through a pubhc switched 
telephone network (PSTN), 

46. Apparatus according to claim 45, wherein when the telephony gateway is further 
coiqjled to the PSTN so as to convey telephone communications between the PSTN and flie 
multiple subscriber premises. 
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